<p>This rule raises an issue when the spread operator (<code>…​</code>) is used in cases where it provides no benefit, such as spreading array
literals directly into arrays, spreading object literals into objects, or converting iterables to arrays when the target already accepts
iterables.</p>
<h2>Why is this an issue?</h2>
<p>The spread operator (<code>…​</code>) is a powerful JavaScript feature for expanding arrays and objects. However, using it unnecessarily can make
code harder to read and potentially less efficient.</p>
<p>There are several common patterns where spread syntax adds no value:</p>
<ul>
  <li> <strong>Spreading literals</strong>: When you spread an array literal <code>[item]</code> directly into another array or function call, you can
  simply write the item directly. </li>
  <li> <strong>Redundant array conversion</strong>: Many JavaScript built-ins like <code>Set</code>, <code>Map</code>, <code>Promise.all()</code>, and
  <code>Array.from()</code> accept any iterable object, not just arrays. Converting an iterable to an array first using spread syntax is unnecessary.
  </li>
  <li> <strong>Iteration contexts</strong>: Language features like <code>for…​of</code> loops and <code>yield*</code> expressions work directly with
  iterables, so spreading them into arrays first is redundant. </li>
</ul>
<p>These unnecessary uses of spread syntax can:</p>
<ul>
  <li> Make code more verbose and harder to read </li>
  <li> Create unnecessary intermediate arrays, potentially impacting performance </li>
  <li> Obscure the intent of the code </li>
  <li> Add cognitive overhead for developers reading the code </li>
</ul>
<h3>What is the potential impact?</h3>
<p>Using unnecessary spread syntax makes code less readable and may create performance overhead by creating intermediate arrays when they’re not
needed. While the performance impact is typically minimal, the readability impact can be significant, especially in codebases with many such
occurrences.</p>
<h3>How to fix?</h3>
<p>Remove unnecessary spread syntax when spreading array literals directly into arrays or function calls.</p>
<h4>Non-compliant code example</h4>
<pre data-diff-id="1" data-diff-type="noncompliant">
const array = [firstElement, ...[secondElement], thirdElement]; // Noncompliant
foo(firstArgument, ...[secondArgument], thirdArgument); // Noncompliant
</pre>
<h4>Compliant code example</h4>
<pre data-diff-id="1" data-diff-type="compliant">
const array = [firstElement, secondElement, thirdElement];
foo(firstArgument, secondArgument, thirdArgument);
</pre>
<h3>Documentation</h3>
<ul>
  <li> <a href="https://github.com/sindresorhus/eslint-plugin-unicorn#readme">eslint-plugin-unicorn</a> - Rule <a
  href="https://github.com/sindresorhus/eslint-plugin-unicorn/blob/HEAD/docs/rules/no-useless-spread.md">no-useless-spread</a> </li>
  <li> MDN - Spread syntax - <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Spread_syntax">Comprehensive guide
  to JavaScript spread syntax</a> </li>
  <li> MDN - Iteration protocols - <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Iteration_protocols">Understanding
  iterables and iterators in JavaScript</a> </li>
</ul>
